SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Interface-based programming</title>

</head>

<span id="openzim-page-title" class="mw-page-title-main"><span class="mw-page-title-main">Interface-based programming</span></span>

</h1>

</header>

/* start https://en.wikipedia.org/ */

.mw-parser-output .ambox{border:1px solid #a2a9b1;border-left:10px solid #36c;background-color:#fbfbfb;box-sizing:border-box}.mw-parser-output .ambox+link+.ambox,.mw-parser-output .ambox+link+style+.ambox,.mw-parser-output .ambox+link+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+style+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+link+.ambox{margin-top:-1px}html body.mediawiki .mw-parser-output .ambox.mbox-small-left{margin:4px 1em 4px 0;overflow:hidden;width:238px;border-collapse:collapse;font-size:88%;line-height:1.25em}.mw-parser-output .ambox-speedy{border-left:10px solid #b32424;background-color:#fee7e6}.mw-parser-output .ambox-delete{border-left:10px solid #b32424}.mw-parser-output .ambox-content{border-left:10px solid #f28500}.mw-parser-output .ambox-style{border-left:10px solid #fc3}.mw-parser-output .ambox-move{border-left:10px solid #9932cc}.mw-parser-output .ambox-protection{border-left:10px solid #a2a9b1}.mw-parser-output .ambox .mbox-text{border:none;padding:0.25em 0.5em;width:100%}.mw-parser-output .ambox .mbox-image{border:none;padding:2px 0 2px 0.5em;text-align:center}.mw-parser-output .ambox .mbox-imageright{border:none;padding:2px 0.5em 2px 0;text-align:center}.mw-parser-output .ambox .mbox-empty-cell{border:none;padding:0;width:1px}.mw-parser-output .ambox .mbox-image-div{width:52px}@media(min-width:720px){.mw-parser-output .ambox{margin:0 10%}}@media print{body.ns-0 .mw-parser-output .ambox{display:none!important}}

/* end https://en.wikipedia.org/ */

</style>

<p><br>

<b>Interface-based programming</b>, also known as <b>interface-based architecture</b>, is an <a href="Architectural_pattern" title="Architectural pattern">architectural pattern</a> for implementing <a href="Modular_programming" title="Modular programming">modular programming</a> at the <a href="Software_component" title="Software component">component</a> level in an <a href="Object-oriented_programming" title="Object-oriented programming">object-oriented programming</a> language which does not have a module system. An example of such a language is <a href="Java_(programming_language)" title="Java (programming language)">Java</a> prior to <a href="Java_version_history#Java_9" title="Java version history">Java 9</a>, which lacked the <a href="Java_Platform_Module_System" title="Java Platform Module System">Java Platform Module System</a>, a module system at the level of components introduced with <a href="Java_version_history#Java_9" title="Java version history">Java 9</a>. <a href="Java_(programming_language)" title="Java (programming language)">Java</a> till <a href="Java_version_history#Java_8" title="Java version history">Java 8</a> merely had a <i>package</i> system, but Java software components typically consist of multiple <a href="Java_package" title="Java package">Java packages</a> – and in any case, interface programming can provide advantages over merely using Java packages, even if a component only consists of a single Java package.

</p><p>Interface-based programming defines the application as a collection of components, in which <a href="Application_Programming_Interface" class="mw-redirect" title="Application Programming Interface">Application Programming Interface</a> (API) calls <i>between</i> components may only be made through abstract interfaces, not concrete classes. Instances of classes will generally be obtained through other interfaces using techniques such as the <a href="Factory_pattern" class="mw-redirect" title="Factory pattern">Factory pattern</a>.

</p><p>This is claimed to increase the <i>modularity</i> of the application and hence its <a href="Maintainability" title="Maintainability">maintainability</a>. However, some caution is warranted – merely splitting an application into arbitrary components communicating via interfaces does not <i>in itself</i> guarantee low <a href="Coupling_(computer_programming)" title="Coupling (computer programming)">coupling</a> or high <a href="Cohesion_(computer_science)" title="Cohesion (computer science)">cohesion</a>, two other attributes that are commonly regarded as key for maintainability.

</p><p>An interface-based architecture can be used when third parties – or indeed separate teams within the same organisation – develop additional components or plugins for an established system. The codebase of the <a href="Eclipse_IDE" class="mw-redirect" title="Eclipse IDE">Eclipse IDE</a> is an example of interface-based programming. Eclipse plugin vendors just have to develop components that satisfy the interface specified by the parent application vendor, the Eclipse Foundation. Indeed, in Eclipse, even the original components such as the Java Development Tools are <i>themselves</i> plugins. This is somewhat like a <a href="Mobile_phone" title="Mobile phone">mobile phone</a> manufacturer specifying a mobile charger interface (pin arrangement, expected <a href="Direct_Currents" title="Direct Currents">direct current</a> voltage, etc.) and both the manufacturer and third parties making their own mobile phone chargers that comply with this standard interface specification.

</p>

<div class="mw-heading mw-heading2"><h2 id="Software_evolution_in_interface-based_programming">Software evolution in interface-based programming</h2></div>

<p>The use of <a href="Interface_(computing)" title="Interface (computing)">interfaces</a> to allow disparate teams to collaborate raises the question of how interface changes happen in interface-based programming. The problem is that if an interface is changed, e.g. by adding a new method, old code written to implement the interface will no longer compile – and in the case of dynamically loaded or linked plugins, will either fail to load or link, or crash at runtime. There are two basic approaches for dealing with this problem:

</p>

<ol><li>a new interface may be developed with additional functionality, which might inherit from the old interface</li>

<li>a <a href="Software_versioning" title="Software versioning">software versioning</a> policy such as <a rel="nofollow" class="external text" href="http://semver.org">semantic versioning 2.0</a> may be communicated to interface implementors, to allow forward-incompatible, or even backward-incompatible, changes in future "major" versions of the platform</li></ol>

<p>Both of these approaches have been used in the Java platform.

</p>

<div class="mw-heading mw-heading2"><h2 id="Design_by_contract">Design by contract</h2></div>

<p>The publisher of the interfaces generally promises that they will not change the interface in new "minor" versions of the software, and the implementer, by implementing the interface, implies that they have implemented at least the required parts of the interface without any deviation. An interface can therefore be viewed as a "contractual agreement" – between a provider and a consumer of the interface. If this contract is documented more formally as a software specification, this is an example of <a href="Design_by_contract" title="Design by contract">design by contract</a>. However, design by contract <i>per se</i> does not mandate the use of interfaces for all components.

</p>

<ul><li><a href="Microservices" title="Microservices">Microservices</a></li>

<li><a href="Actor_model" title="Actor model">Actor model</a></li>

<li><a href="CORBA" class="mw-redirect" title="CORBA">CORBA</a>, an older component-based system for object-oriented software which is now rarely used, for various reasons</li>

<li><a href="Java_Platform_Module_System" title="Java Platform Module System">Java Platform Module System</a>, a module system at component level for the <a href="Java_(programming_language)" title="Java (programming language)">Java</a> programming language introduced with <a href="Java_version_history#Java_9" title="Java version history">Java 9</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="References">References</h2></div>

<ul><li><a rel="nofollow" class="external text" href="http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_interrfaces03052006095933AM/csharp_interrfaces.aspx">C# Interface Based Development</a>, c-sharpcorner.com</li>

<li><a rel="nofollow" class="external text" href="https://archive.today/20130414134941/http://devmentor.org/references/uml/interface.php">Interface Based Development – The Unified Modeling Language (UML)</a>, devmentor.org</li>

<li><a rel="nofollow" class="external text" href="http://www.rhyous.com/2011/10/18/architecting-a-large-application-with-interface-based-architecture/">Architecting a large application with interface-based architecture</a>, rhyous.com, 18 October 2011</li>

<li><a rel="nofollow" class="external text" href="http://msdn.microsoft.com/en-us/library/aa260635%28v=vs.60%29.aspx">Understanding Interface-based Programming</a>, <a href="Microsoft_Developers_Network" class="mw-redirect" title="Microsoft Developers Network">Microsoft Developers Network</a>, accessed 16 September 2016</li></ul></div><div><div class="zim-footer">

This article is issued from <a class="external text" title="Last edited on 2024-02-13" href="https://en.wikipedia.org/wiki/?title=Interface-based_programming&oldid=1207086963">Wikipedia</a>. The text is available under <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.en">Creative Commons Attribution-Share Alike 4.0</a> unless otherwise noted. Additional terms may apply for the media files.

</div>

</div></div>

</div>

</main>

</div>

</body></html>